Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as with the computing systems being co-located (e.g., as part of a local network) or instead located in multiple distinct geographical locations (e.g., connected via one or more private or public intermediate networks). For example, distributed systems housing significant numbers of interconnected computing systems have become commonplace.
Some data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other data center operators provide “full service” facilities that also include hardware resources made available for use by their customers. Such resources at data centers, when accessed by remote customers, may be said to reside “in the cloud” and may be referred to as cloud computing resources or provider network resources.
Several different kinds of back-end services may be made accessible to large numbers of clients of provider network or cloud environments, including various types of virtualized computing services, storage or database services, services optimized for application domains such as artificial intelligence and the like. In many cases, the kinds of tasks that clients wish to have performed at provider networks may potentially involve the use of several different kinds of resources and/or services to implement respective sub-tasks. The services themselves may require the use of respective distinct programmatic interfaces, and the times taken to complete individual sub-tasks may vary widely. As a result, coordinating the different sub-tasks of a multi-resource or multi-service application may present a non-trivial challenge. Testing and debugging such applications may also be difficult, especially when individual sub-tasks may have side effects that are hard to detect.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to. When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof.